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I. Real Party in Interest 

The Real Party in Interest for the appealed application is Computer Sciences Corporation. 

II. Related Appeals and Interferences 

There are no related appeals or interferences that will directly affect or be directly 
affected by or have a bearing on the Board's decision in the pending appeal. 

III. Status of Claims 

Claims 1-78 have been entered in the case. Claims 1-5 and 21-77 have been cancelled. 
Claims 6-20 and 78 are pending. Claims 6-20 and 78 have been rejected. No claims have been 
allowed. Claims 6-20 and 78 are being appealed. 

IV. Status of Amendments 

The Appellant is filing an amendment on March 12, 2007. For the reasons explained in 
the Remarks section of that amendment, Appellant believes that that amendment is entitled to 
entry under the standards set forth in MPEP §1207. 

V. Summary of Invention 

This invention generally relates to a method for configuring a Financial Service 
Organization (FSO) production system database. See Specification, page 1, lines 12-14 (all 
future page, paragraph, and line references in this section refer to the Specification unless 
otherwise indicated). 

Financial service organizations (FSOs) such as banks, credit unions, etc., use computer 
systems running software programs to process FSO transactions. The processing parameters 
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used by the FSO system in processing transactions, may be embedded in the source code of the 
FSO system software programs, or the processing parameters may be stored in one or more tables 
in an FSO system database. Processing parameters may be used to apply business logic to the 
transactions during processing. A processing parameter may have different values for different 
transactions based upon one or more attributes of the transactions. For example, the processing 
parameter values used in processing a customer credit card transaction made at one department 
store may be different than the processing parameter values used in processing a customer credit 
card transaction made at a different department store. (See page 1, line 18 to page 2, line 9). 

A set of data elements useable to determine the value of a processing parameter for a 
transaction may be referred to as a key definition for the processing parameter. Data element 
values may be extracted from a transaction data set and an associated master file by using the 
data elements in the key definition to locate the data element values. (See page 2, lines 9-18). 

In some FSO systems, the key definitions, processing parameters, and corresponding key 
values used to identify and select the processing parameters may be hardcoded in the source code 
for the FSO system software programs. Modifying the key definitions, processing parameters, 
and corresponding key values involves modifying the source code for all software programs that 
use these items, recompiling and relinking the programs, and reinstalling the software programs. 
As a result, these FSO systems are not flexible in the configuration and use of processing 
parameters. Any modification to the hardcode must be made by one or more people with 
sophisticated educational backgrounds and a sufficient understanding of the FSO system. 
Moreover, the time needed to implement and test modifications to existing FSO systems makes it 
difficult for FSOs to respond to rapidly changing business strategies. (See page 2, line 20 to page 
3, line 25.) 

Recognizing the drawbacks of conventional FSO system software programs, Appellant 
developed new methods for configuring a Financial Service Organization (FSO) production 
system databases. 
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Independent claim 6 is directed to a method that includes displaying key element 
representations on a display screen in data communication with a Financial Service Organization 
(FSO) computer system comprising a database. (See page 21, line 27 to page 22, line 8). The 
FSO computer system is configured to perform processing on FSO transaction-related data. (See 
page 13, line 9-14). A user selects at least two key element representations from the displayed 
key element representations. (See page 18, lines 6-10). In response to the user selecting at least 
two key element representations, a key definition is prepared from the key elements 
corresponding to selected key element representations. (See page 22, line 26 to page 23, line 12). 
The key definitions are stored in the database. (See page 5, line 19-20). The key definitions are 
configured for use in preparing a processing key value from a transaction-related data in the FSO 
computer system. The processing key value is configured for use in locating a process control 
data set in the database in the FSO computer system. (See page 5, line 12 to page 6, line 10). 
The process control data set includes one or more process control data values and is configured 
for use in processing the transaction-related data in the FSO computer system. (See page 28, 
lines 15-25; page 30, line 2 to page 31, line 14). 

Independent claim 78 is directed to a method that includes displaying on a display screen 
coupled to a financial service organization computer system a dictionary of data elements 
including one or more data elements associated with an FSO transaction-related data. (See page 
12, lines 10-21; page 18, lines 4-11). The FSO computer system is configured to perform 
processing on FSO transaction-related data. (See page 13, line 9-14). A user selects at least two 
key element representations from the displayed key element representations. (See page 18, lines 
6-10). An input is received from the user, for each of the selected data elements, in which the 
user specifies the place of the data element in a sequence of the data elements. (See page 18, 
lines 10-11; page 22, lines 5-21). The selected data elements in the user- specified sequence 
define a user-defined key. (See page 18, lines 10-11; page 22, lines 5-21). The user-defined key 
is configured during a configuration of the FSO computer system. (See page 6, line 27 to page 7, 
line 4). The user-defined key describes a location of one or more corresponding data element 
values stored in an FSO database. (See page 5, lines 27-28). The user-defined key is stored in 
the FSO database. (See page 5, line 19-20). 
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VI. Grounds of Rejection to be Reviewed on Appeal 

1. Claims 6-16 and 78 are finally rejected under 35 U.S.C. §103(a) as being obvious over U.S. 
Patent No. 5,794,229 to French et al. (hereinafter "French"). 

2. Claims 17-20 are finally rejected under 35 U.S.C. § 103(a) as being obvious over French in 
view of U.S. Patent No. 5,995,971 to Douceur et al. (hereinafter "Douceur"). 

VII. Argument 

First Ground of Rejection 

Claims 6-16 and 78 are finally rejected under 35 U.S.C. §103(a) as being obvious over 
French. Appellant traverses this rejection for the following reasons. Different groups of claims 
are addressed under their respective subheadings. 

Claim 6 

In order to reject a claim as obvious, the Examiner has the burden of establishing a prima 
facie case of obviousness. In re Warner et al., 379 F.2d 1011, 154 U.S.P.Q. 173, 177-178 
(C.C.P.A. 1967). To establish a prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. (emphasis added) In re Royka, 490 F.2d 
981, 180 U.S.P.Q. 580 (C.C.P.A. 1974), MPEP § 2143.03. "All the words in a claim must be 
considered in judging the patentability of that claim against the prior art." (emphasis added) In 
re Wilson, 424 F.2d 1382, 1385 (C.C.P.A. 1970). In addition, there must be some suggestion or 
motivation, either in the references themselves or in the knowledge generally available to one of 
ordinary skill in the art, to modify the reference or to combine reference teachings. In re Vaeck, 
947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). 
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Claim 6 describes a method that has a combination of features including: 

preparing a key definition from the two or more key elements corresponding to the 
at least two selected key element representations in response to the user selecting the 
at least two key element representations; and 

storing the key definition in the database; the key definition being configured for 
use in preparing a processing key value from a transaction-related data in the FSO 
computer system, 

wherein the processing key value is configured for use in locating a process 
control data set in the database in the FSO computer system, the process control data 
set comprising one or more process control data values and configured for use in 
processing the transaction-related data in the FSO computer system. 

Appellant submits that the cited art, separately or in combination, does not teach or suggest the 
above-quoted features of claim 6, in combination with the other features of the claim. Claim 6 is 
directed to a method that includes displaying key element representations on a display screen in 
communication with a Financial Service Organization (FSO) computer system. A processing key 
value is configured for use in locating a process control data set in the database in the FSO 
computer system. The process control data set comprising one or more process control data 
values and configured for use in processing the transaction-related data in the FSO computer 
system. Appellant's specification states, for example, "The tables in the database that store the 
processing parameters and keys may be referred to as Process Control Data (PCD) tables." (See 
page 14, lines 18-19) 

Regarding the feature "wherein the processing key value is configured for use in locating 
a process control data set in the database in the FSO computer system, the process control data 
set comprising one or more process control data values and configured for use in processing the 
transaction-related data in the FSO computer system", the Examiner relies on a portion of French 
which states: 



In operation, the Client(s) issue one or more SQL commands to the Server. SQL 
commands may specify, for instance, a query for retrieving particular data (i.e., data 
records meeting the query condition) from the table 250. The syntax of SQL 
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(Structured Query Language) is well documented; see, e.g., the above-mentioned An 
Introduction to Database Systems. In addition to retrieving the data from Database 
Server tables, the Client(s) also include the ability to insert new rows of data records 
into the table; Client(s) can also modify and/or delete existing records in the table. 

For enhancing the speed in which the Database Server stores, retrieves, and presents 
particular data records, the Server maintains one or more database indexes 271 on the 
table, under control of an Index Manager. A database index, typically maintained as a 
B-Tree data structure, allows the records of a table to be organized in many different 
ways, depending on a particular user's needs. An index may be constructed as a single 
disk file storing index key values together with unique record numbers. The former is 
a data quantity composed of one or more fields from a record; the values are used to 
arrange (logically) the database file records by some desired order (index expression). 
(French, column 7, lines 7-27). 

The Examiner states: "(col. 7, lines 7-27 -the result when a SQL Query is run. The result will 
be displayed of all of the data in the SALES and DATE OF SALE columns)". Appellant 
disagrees that French teaches or suggests the above-quoted feature of claim 6. French discloses 
a client issuing SQL commands to a server to retrieve data. A database index allows records to 
be organized in many different ways. Appellant submits that French does not teach or suggest a 
processing key value configured for use in locating a process control data set in a database in the 
FSO computer system, the process control data set including one or more process control data 
values and configured for use in processing the transaction-related data. Moreover, French does 
not teach or suggest a process control data set configured for use in processing transaction-related 
data in a financial service organization computer system. 



Regarding the feature "storing the key definition in the database; the key definition being 
configured for use in preparing a processing key value from a transaction-related data in the FSO 
computer system", the Examiner relies on French, col. 12, line 37-col. 13, line 3. The cited 
portion of French describes storing data in a column-wise basis, wherein a query can bring in only 
those columns of data that are of interest. The Examiner states "storing the key definition is 
inherent since it is simply saving the SQL statement because the SQL statement has to be saved 
somewhere on the computer in order for it to be seen." To rely on the theory of inherency, the 
examiner must "provide a basis in fact and/or technical reasoning to reasonably support the 
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determination that the allegedly inherent characteristic necessarily flows from the teachings of the 
applied prior art." Ex parte Levy, 17 U.S.P.Q.2d 1461, 1464 (Bd. Pat. App. & Inter. 1990) 
(emphasis in original.) Inherency may not be established by probabilities or possibilities; the mere 
fact that a certain thing may result from a given set of circumstances is not sufficient. In re 
Robertson, 169 F.3d 743, 745 (Fed. Cir. 1999). Even if the SQL statement described in French 
had to be stored somewhere to be displayed, as the Examiner contends, Appellant submits that it 
is not inherent in French, and nothing in French teaches or suggests, the features of claim 6 of 
storing a key definition in a database, the key definition configured for use in preparing a 
processing key value from a transaction-related data in an FSO computer system. 

For at least these reasons, Appellant submits that claim 6 is allowable over the cited art. 
Claim 7 

Claim 7 recites, in part, "wherein the user selecting the key element representations, the 
preparing the key definition, and the storing the key definition occur during a configuration of the 
FSO computer system." Appellant submits that the cited art does not appear to teach or suggest 
this feature, in combination with the features of independent claim 6, for at least the reasons cited 
above. Furthermore, with regard to this feature, the Examiner cites column 7, lines 36-67, 
column 12, line 10 to column 13, line 3, and Fig. 3B of French. Appellant submits that the cited 
portions of French appear to relate to a server maintaining database indexes on tables, under the 
control of an Index Manager. In operation SQL statements received frm the clients are processed 
by an engine of the database server system. (See, e.g., French, column 7, lines 15-38). The cited 
portions further disclose queries encountered in decision support system (DSS) applications, and 
storing data in a column-wise basis to process such queries. (French, e.g., column 12, lines 10- 
61). French does not appear to teach or suggest configuration of financial service organization 
computer systems. Moreover, Claim 7 is directed to a method that includes selecting key 
element representations, and preparing and storing of a key definition occur during a 
configuration of a financial service organization (FSO) computer system. For example, 
Appellant's specification states: 
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In one embodiment, the key definitions, key values, processing parameter values, 
and search masks may be constructed and stored during the configuration of the 
FSO system. Configuration of the FSO system may occur at the time the FSO 
system software programs and databases are initially installed and set up for 
processing FSO transactions. Configuration of the FSO system may also occur 
after the initial configuration performed during the installation of the FSO system. 
A configuration of the FSO system that occurs after the initial configuration may 
be called a reconfiguration of the FSO system, 
(page 6, line 27 to page 7, line 4) 

Appellant submits that the cited portions of French do not appear to teach or suggest the user 
selecting the key element representations, preparing the key definition, and the storing the key 
definition occur during a configuration of a financial service organization computer system. As 
such, Appellant submits that the cited art does not appear to teach at least this feature in 
combination with the other features of the cited art. 

Claim 8 



Claim 8 recites, in part, "wherein the preparing the key definition from the one or more 
key elements further comprises the user specifying a sequence of the key elements in the key 
definition, wherein the user specifying a sequence of the key elements in the key definition 
comprises the user specifying the place of each of the selected key data element in a sequence of 
the selected key data elements for the key definition." Appellant submits that the cited art does 
not appear to teach or suggest this feature, in combination with the features of independent claim 
6, for at least the reasons cited above. Furthermore, with regard to this feature, the Examiner 
cites column 7, lines 2-24 of French, which state: 



... In the foregoing employee table, for example, Position is one field, Date Hired is 
another, and so on. With this format, tables are easy for users to understand and use. 
Moreover, the flexibility of tables permits a user to define relationships between 
various items of data, as needed. 

In operation, the Client(s) issue one or more SQL commands to the Server. SQL 
commands may specify, for instance, a query for retrieving particular data (i.e., data 
records meeting the query condition) from the table 250. The syntax of SQL 
(Structured Query Language) is well documented; see, e.g., the above-mentioned An 
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Introduction to Database Systems. In addition to retrieving the data from Database 
Server tables, the Client(s) also include the ability to insert new rows of data records 
into the table; Client(s) can also modify and/or delete existing records in the table. 

For enhancing the speed in which the Database Server stores, retrieves, and presents 
particular data records, the Server maintains one or more database indexes 271 on the 
table, under control of an Index Manager. A database index, typically maintained as a 
B-Tree data structure, allows the records of a table to be organized in many different 
ways, depending on a particular user's needs. An index may be constructed as a single 
disk file storing index key values together with unique record numbers. 
(French, column 7, lines 2-24). 

Appellant submits that the cited portions of French appear to relate to a client issuing SQL 
commands to a server to retrieve particular data. Data indexes, such as in a B-Tree data 
structure, allow records to be organized in different ways. Appellant submits that the cited 
portions of French do not teach or suggest a method in which preparing the key definition from 
key elements further includes the user specifying a sequence of the key elements in the key 
definition , wherein the user specifying a sequence of the key elements in the key definition 
comprises the user specifying the place of each of the selected key data element in a sequence of 
the selected key data elements for the key definition. As such, Appellant submits that the cited 
art does not appear to teach at least this feature in combination with the other features of the cited 



Claim 10 



Claim 10 recites, in part, "the user defining one or more key values for the key definition; 
the user defining a processing parameter value for each of the key values for the key definition; 
and storing the one or more key values and processing parameter values in the database; wherein 
locating the processing parameter value using the constructed processing key value comprises 
matching the constructed processing key value with one of the one or more key values stored in 
the database." Appellant submits that the cited art does not appear to teach or suggest this 
feature, in combination with the features of independent claim 6, for at least the reasons cited 
above. 
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Claim 12 



Claim 12 recites, in part, "wherein the database comprises a process control data table 
associated with the key definition, wherein the process control data table comprises one or more 
rows, and wherein each row in the process control data table comprises one or more fields for 
storing one key value and one or more fields for storing the processing parameter value for the 
key value stored in the row." Appellant submits that the cited art does not appear to teach or 
suggest this feature, in combination with the features of independent claim 6, for at least the 
reasons cited above. 

Claim 78 

Claim 78 describes a method that has a combination of features including: 

receiving, for each of the selected data elements from the user an input 
specifying the place of the data element in a sequence of the two or more data 
elements, 

the selected data elements in the user- specified sequence defining a user- 
defined key, the user-defined key being configured during a configuration of the FSO 
computer system and describing a location of one or more corresponding data 
element values stored in an FSO database; 

Appellant submits that the cited art, separately or in combination, does not teach or suggest the 
above-quoted features of claim 78, in combination with the other features of the claim. 



Claim 78 is directed to a method in which, during a configuration of a financial service 

organization computer system, for each of two or more selected data elements, the user enters an 

input to specify the place of the data element in a sequence. This sequence defines a user-defined 

key. Regarding the above-quoted features of claim 78, the Examiner relies on column 11, line 

46 to column 12, line 7 of French, which state: 

According to the present invention, the Index Manager is "taught more" about the 
problem or query at hand. In a conventional system (e.g., Oracle), the Query 
Optimizer generally asks the indexes only simple questions, such as "what is the 
record for Account No. 35?" In the system of the present invention, in contrast, 
additional complexity has been pushed from the Optimizer down to a level which 
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is closer to the data. In addition to requests for returning a particular record (e.g., 
return the record for Account No. 35) in the system, operations such as SUM, 
AVG, MIN, MAX, COUNT DISTINCT, and the like are performed at the level of 
the data objects (e.g., data pages). Because the indexes understand the distribution 
of the data, the cardinality of the data, the range of values of the data, and the like, 
the indexes are much closer to the physical problem. They understand the physical 
nature of that column's attributes. As a result, they are better suited for these types 
of operations. 

In the case of the low cardinality value-based indexing technique, doing a 
GROUP BY is computationally cheap, because the index is ordered by group. 
Similarly, COUNT DISTINCT is computationally cheap; COUNT DISTINCT is 
another way of grouping things. SUM is also reasonably cheap. Consider a query 
on the number of dependents, a low cardinality field (e.g., values ranging from 1 
to 10). Here, the system need only access the corresponding bit maps (i.e., 10 bit 
maps) for quickly determining how many bits are on. The Index Manager is 
modified to include an interface which allows it to receive some of the query 
information returning a page and offset for a given key value. 
(French, column 11, line 46, to column 12, line 7) 



French discloses an system in which an Index Manager is "taught more" about a problem or 
query at hand. French further discloses that indexes may be ordered in different ways such as 
GROUP BY, COUNT DISTINCT, and SUM. The Index Manager may include an interface 
which allows it to receive some of the query information returning a page and offset for a given 
key value. French does not appear to relate to defining a sequence of elements in a key. 
Moreover, Appellant submits that French does not teach or suggest receiving from a user, for 
each of two or more selected data elements displayed, an input specifying the place of the data 
element in a sequence of the two or more data elements, the selected data elements in the user- 
specified sequence defining a user-defined key, the user-defined key being configured during a 
configuration of a financial service organization (FSO) computer system. 
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Second Ground of Rejection 

Claims 17-20 are finally rejected under 35 U.S.C. § 103(a) as being obvious over French 
in view of Douceur. Appellant traverse this rejection for the following reasons. Different groups 
of claims are addressed under their respective subheadings. 

Claim 17 

Claim 17 recites, in part, "wherein said specifying the message text of each entry in the 
database comprises modifying the message text of at least one of the entries in the database 
during the installation of the insurance claims processing program on the computer system." 
Appellant submits that the cited art does not appear to teach or suggest this feature, in 
combination with the features of independent claim 6, for at least the reasons cited above. 

Claim 18 

Claim 18 recites, in part, "wherein the user defining the one or more key masks further 
comprises the user selecting a mask field value from a plurality of mask field values for each of 
the one or more mask fields in each of the one or more key masks, and wherein the plurality of 
mask field values comprises an equal mask field value and a wildcard mask field value." 
Appellant submits that the cited art does not appear to teach or suggest this feature, in 
combination with the features of independent claim 6, for at least the reasons cited above. 

Furthermore, claim 18 is directed to a method that includes a user defining key mask field 
values for mask fields in one or more masks in which the mask field values include an equal 
mask field value and a wildcard mask field value. For example, Appellant's specification states: 

In one embodiment of a search mask table, mask field values may include 
an equal mask field values and a wildcard mask field value. In one embodiment, 
an equal mask field value may be entered by the user and displayed on the search 
mask entry display screen as an equal sign ("="), as illustrated in Figure 9. In one 
embodiment, a wildcard mask field value may be entered by the user and 
displayed on the search mask entry display screen as an asterisk ("*"), as 
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illustrated in Figure 9. In one embodiment, an equal mask field value in a mask 
field may specify that, when constructing a processing key value from the data 
element values in a customer account data set during processing of the customer 
account data set, the key element value in the processing key value corresponding 
to the mask field will be set to the data element value from the customer account 
data set. In one embodiment, a wildcard mask field value in a mask field may 
specify that, when constructing a processing key value from the data element 
values in a customer account data set during processing of the customer account 
data set, the key element value in the processing key value corresponding to the 
mask field will be set to the low collating value for the data type of the key 
element. 

(Appellant's specification, page 25, line 26 to page 26, line 11). 

The Examiner relies on Douceur, column 26, line 43 to column 27, line 62, for the above-quoted 
features of claim 18. The cited portions of Douceur discloses VALUE, MASK, and IMASK. 
Douceur further discloses that the purpose of each field differs between a pattern node and a 
branch node. The MASK field may specify the existence of a wildcard in the corresponding 
pattern. Appellant submits that Douceur does not teach or suggest a user defining the one or 
more key masks in which the user selects a mask field value from a plurality of mask field values 
for each of the one or more mask fields in each of the one or more key masks, and in which the 
plurality of mask field values comprises an equal mask field value and a wildcard mask field 
value . 

Claim 19 



Claim 19 recites, in part, "wherein the transaction-related data comprises a credit card 
transaction, and wherein the processing parameter value comprises one or more data values 
configured for processing the credit card transaction." Appellant submits that the cited art does 
not appear to teach or suggest this feature, in combination with the features of independent claim 
6, for at least the reasons cited above. Furthermore, with regard to this feature, the Examiner 
states: 

It would have been obvious to one having ordinary skill in the art at the time 
the invention was made to have the transaction-related data comprise a credit card 
transaction, and wherein the processing parameter value comprises one or more data 
values configured for processing the credit card transaction and to modify in French 
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since French does disclose product, price, and revenue in col. 12, lines 15-25 and 
because such a modification would allow French to have financial transaction data 
retained by a transaction processing system. 

Appellant disagrees with the Examiner's assertion. The cited portion of French states: 



SELECT Age, Gender, SUM(Revenue), COUNT(*) 
FROM Customers 

WHERE State IN ('MA', 'NY', 'RI', 'CT') 

AND Status = 'Active' 
GROUP BY Age, Gender; 
SELECT State, Product, SUM(Revenue), AVG(Price) 
FROM Customers 
WHERE Product <> 'b' 

AND Code = 1 
GROUP BY State, Product 



(French, column 12, lines 15-25) 



Appellant submits that the cited portions of French do not teach or suggest the transaction-related 
data comprises a credit card transaction, and wherein the processing parameter value comprises 
one or more data values configured for processing the credit card transaction. Moreover, 
French is directed toward solutions for "Decision Support Systems" for analytical processing. 
French appears to teach away from configuring records of a database for transaction processing. 
For example, French states: 



The following description will focus on specific modifications to an SQL- 
based database server, such as System 240, for providing improved Decision Support 
query performance. 

A. DSS queries require a different design approach 

The present invention recognizes that the previously-described "needle-in-a- 
haystack" approach to information retrieval employed in OLTP [online transaction 
processing] environments is not well-suited for Decision Support Systems (DSS) 
applications. DSS applications, such as those used in conjunction with providing a 
"data warehouse," are employed for more analytical information processing. Instead 
of employing a simple query for pulling up records of a particular customer, a DSS 
query typically seeks information of a more general nature. A typical DSS query 



15 



Inventor: Steven G. Doughty 
Appl. Ser. No.: 09/699,037 
Atty. Dckt. No.: 5053-31401 



would, for instance, ask how many customers living in Massachusetts purchased 
more than thirty dollars of merchandise over the past year. To satisfy a query of this 
nature, a database system would have to examine a large percentage of the actual 
warehouse data, not just a few records. 

In fact, the individual records found in a DSS query are often not of interest to the 

user Here, the sum of a particular category is more of interest to the user than the 

detail records of the particular transactions which contributed to that sum. 

The poor performance of OLTP systems in providing DSS stems from the 
architecture and design considerations underlying these systems. Quite simply, OLTP 
database engines have been architected and optimized for transaction processing to 
such an extent that they are not well-suited for analytical processing . The problem is 
due, in part, to how information is actually stored in OLTP systems. Such systems 
store rows of records arranged in a list of data pages (i.e., page "chain"). That 
approach is well- suited for transaction processing. When a system needs to retrieve a 
particular record, it need only bring in the corresponding data page which stores that 
record. If, on the other hand, analytical processing is required, this horizontal 
approach (i.e., storing particular rows to each data page) hampers system 
performance . A DSS query might, for instance, require the system to examine values 
in a particular column (or a few columns). Since the information is stored by row 
(i.e., horizontally) and not by column (i.e., vertically) in OLTP systems, those 
systems have to bring in all data pages in order to perform the DSS query. The 
underlying storage mechanism employed in OLTP systems, while perhaps optimal 
for transaction processing, is clearly suboptimal for Decision Support applications . 
Typical DSS queries look at several tables but only a small number of columns 
(relative to the total number of columns for a table). A system using the OLTP 
approach to storing data would have to bring in a multitude of data pages— data pages 
which largely consist of information which is simply not of interest in DSS queries. 
(French, column 8, line 15 to column 9, line 7) (emphasis added) 

Thus, French appears to teach away from the features of claim 19 wherein the processing 
parameter value includes data values configured for processing transactions. For at least this 
reason, Appellant submits that it would not have been obvious to modify French as proposed by 
the Examiner such that a processing parameter value includes data values configured for 
processing a credit card transaction. 
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VIII. Conclusion 



For the foregoing reasons, it is submitted that the Examiner's rejection of claims 6-20 and 
78 was erroneous, and reversal of the Examiner's decision is respectfully requested. 



If any extension of time is required, Appellant hereby requests the appropriate extension 
of time. If any fees are omitted or if any additional fees are required or have been overpaid, 
please appropriately charge or credit those fees to Meyertons, Hood, Kivlin, Kowert & Goetzel, 
P.C. Deposit Account Number 50-1505/5053-31401/EBM. 

Respectfully submitted, 
/Chris D. Thompson/ 

Chris D. Thompson 
Reg. No. 43,188 
Attorney for Appellant 

Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

(512) 853-8800 (voice) 

(512) 853-8801 (facsimile) 

Date: June 8, 2007 
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IX. Claims Appendix 
The claims on appeal are as follows: 

6. A computer-implemented method comprising: 

displaying two or more key element representations on a display screen in data 
communication with a Financial Service Organization (FSO) computer system comprising a 
database, the FSO computer system being configured to perform processing on FSO transaction- 
related data; 

receiving a selection by a user of at least two key element representations from the two or 
more displayed key element representations; 

preparing a key definition from the two or more key elements corresponding to the at 
least two selected key element representations in response to the user selecting the at least two 
key element representations; and 

storing the key definition in the database; the key definition being configured for use in 
preparing a processing key value from a transaction-related data in the FSO computer system, 

wherein the processing key value is configured for use in locating a process control data 
set in the database in the FSO computer system, the process control data set comprising one or 
more process control data values and configured for use in processing the transaction-related data 
in the FSO computer system. 

7. The method of claim 6, wherein the user selecting the key element representations, the 
preparing the key definition, and the storing the key definition occur during a configuration of the 
FSO computer system. 

8. The method of claim 6, wherein the preparing the key definition from the one or more key 
elements further comprises the user specifying a sequence of the key elements in the key 
definition, wherein the user specifying a sequence of the key elements in the key definition 
comprises the user specifying the place of each of the selected key data element in a sequence of 
the selected key data elements for the key definition. 
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9. The method of claim 6, wherein the database comprises a plurality of data elements, and 
wherein the method further comprises: 

the user selecting a plurality of key elements for use in key definitions from the plurality 
of data elements; and 

the user selecting the one or more key elements for displaying on the display screen from 
the plurality of key elements. 

10. The method of claim 6, further comprising: 

the user defining one or more key values for the key definition; 
the user defining a processing parameter value for each of the key values for the key 
definition; and 

storing the one or more key values and processing parameter values in the database; 

wherein locating the processing parameter value using the constructed processing key 
value comprises matching the constructed processing key value with one of the one or more key 
values stored in the database. 

11. The method of claim 10, wherein each of the one or more key values is unique among the 
one or more key values for the key definition. 

12. The method of claim 10, wherein the database comprises a process control data table 
associated with the key definition, wherein the process control data table comprises one or more 
rows, and wherein each row in the process control data table comprises one or more fields for 
storing one key value and one or more fields for storing the processing parameter value for the 
key value stored in the row. 

13. The method of claim 10, wherein each of the one or more key values comprises one key 
element value for each of the one or more key elements in the key definition, and wherein the 
user defining the one or more key values for the key definition further comprises the user 
defining the one or more key element values for each of the one or more key values. 
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14. The method of claim 13, wherein the user defining the one or more key element values 
for each of the one or more key values comprises the user selecting a key element value for each 
of the one or more key elements in the key definition from a plurality of available key element 
values for the key element. 

15. The method of claim 14, wherein the plurality of available key element values comprises 
a wildcard key element value. 

16. The method of claim 6, wherein the database is relational or is object-oriented. 

17. The method of claim 6, further comprising: 

the user defining one or more key masks for the key definition, wherein each key mask 
comprises one or more mask fields, wherein the one or more mask fields in the key mask 
correspond to the one or more key elements in the key definition; and 

storing the one or more key masks in the database. 

18. The method of claim 16, wherein the user defining the one or more key masks further 
comprises the user selecting a mask field value from a plurality of mask field values for each of 
the one or more mask fields in each of the one or more key masks, and wherein the plurality of 
mask field values comprises an equal mask field value and a wildcard mask field value. 

19. The method of claim 6, wherein the transaction-related data comprises a credit card 
transaction, and wherein the processing parameter value comprises one or more data values 
configured for processing the credit card transaction. 

20. The method of claim 18, wherein the processing parameter value comprises one or more 
merchant transaction pricing values. 
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78. A computer-implemented method comprising: 

displaying on a display screen coupled to a Financial Service Organization (FSO) 
computer system a dictionary of data elements comprising one or more data elements associated 
with an FSO transaction-related data, the FSO computer system being configured to process the 
transaction-related data; 

receiving a selection by a user of two or more data elements selected from the dictionary 
of data elements; 

receiving, for each of the selected data elements from the user an input specifying the 
place of the data element in a sequence of the two or more data elements, 

the selected data elements in the user-specified sequence defining a user-defined key, the 
user-defined key being configured during a configuration of the FSO computer system and 
describing a location of one or more corresponding data element values stored in an FSO 
database; and 

storing the user-defined key in the FSO database. 
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X. Evidence Appendix 



No evidence submitted under 37 CFR §§ 1.130, 1.131 or 1.132 or otherwise entered by 
the Examiner is relied upon in this appeal. 
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XI. Related Proceedings Appendix 



There are no related proceedings. 



23 



